import java.util.ArrayList;
import java.util.HashMap;
import java.util.concurrent.TimeUnit;

/**
 * 描述:项目
 * 1.系统的安全性如何保证？
 *      1.使用https
 *      2.对外提供接口采用签名校验的方式
 *      3.XSS跨站脚本攻击防御，定义Xss filter过滤敏感字符串
 *      4.sql注入防御，后端使用mybatis的#{}
 *      5.用疑似脚本，对服务器发起大批量的请求，用nginx的一个Http模块，可以拦截请求频率太高的ip
 *      6.前后端密码密文传输，用的sm2对称加密，然后存到数据库中的密码用的是sm4非对称加密，项目中配置文件的密码也要加密
 * 2.JAVA线上问题排查
 *      1.代码类问题：
 *          1.线上排查
 *              1.cpu占用高：top命令，默认cpu排序，查看cpu%比，如果cpu占用高，则找到高的进程 top -Hp 进程id，然后得到这个进程id的各个线程Id，
 *                  cpu满了一般是出现死循环等情况，jstack -l 线程id ，再printf %x pid 得到id的十六进制，然后去jstack中查找问题，若是死锁，一般是线程再wait to lock monitor
 *              2.内存情况：free查看剩余内存，够的话，top查看哪个进程占用内存高，top -Hp 查看哪个线程占用内存高，再jstack或者dump处理
 *              3.磁盘情况：df -hl查看磁盘情况，du -sh查看当前目录大小
 *              4.内存溢出：日志文件中出现oom，然后 jmap -dump:format=b,file=heapdump.phrof pid，得到dump文件，或者设置一个配置自动dump，放入mat分析，查看内存情况，
 *              5.频繁GC：有个配置，可以打印GC的情况
 *                  1.堆内存太小
 *                  2.年轻代gc年龄设置的太小
 *                  3.停顿时间设置的不合理
 *          2.线下排查：
 *              1.如果是windows服务器，我一般直接jvisualVM查看当前gc情况，线程dump情况等等，需要安装插件
 *              2.linux用jmap生成dump文件 jmap -dump:format=b,file=heapdump.phrof pid
 *              3.然后后Mat去分析对象数量，内存泄漏情况等等
 *      2.TCP问题排查
 *          1.netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'查看tcp连接数状态
 *          2.netstat -ant |grep 端口|wc -l 统计出某个端口的连接数，统计establish，time_wait连接数
 *          3.如发现系统存在大量TIME_WAIT状态的连接，通过调整内核参数解决
 *      3.总结
 *          1.查看日志
 *          2.查看CPU情况
 *          3.查看TCP情况
 *          4.查看java线程，jstack
 *          5.查看java堆，jmap
 *          6.通过MAT分析堆文件，寻找无法被回收的对象
 * 3.描述:你有没做过什么项目比较印象深刻的
 *      1.旧版
 *          1.以前做过一个预约的系统，疫情期间，政府免费发放口罩，当时口罩还挺值钱的，而且大家都急缺，所以预约的人很多
 *          2.然后我们小组讨论了很多技术上的实现，并且在架构师的指导下，将一个qps只有四百的服务，升级到了五六千这样
 *          3.当时这个系统存在这么几个问题吧：
 *              1.测试用jmater在做压测的时候，预约的页面加载卡顿，url访问非常慢，然后发现，前端页面加上图片等资源，总共有接近4M，
 *                  每次加载都要加载4M，就查阅资料，开启了Nginx的一个叫gzip压缩技术，还有开启了niginx缓存，然后页面是加载快了，但是预约的
 *                  那个接口从点击到返回，要56s的时间，如果并发量一大，就需要更长甚至没反应了
 *              2.查看了端口的连接状态，发现TIME_WAIT状态的连接数非常多，说明系统处理业务的速度太慢了，处理不来，很多连接卡住了，
 *                  然后架构师就建议开放linux的tcp端口到65535个，还开启一个端口快速重用的配置
 *              3.业务上代码的问题有
 *                  1.需要掉三个接口，每个接口都要平均1s的时间，什么身份校验接口啥的，然后解决办法是定义了一个线程池，
 *                      40个核心线程，超时时间为1分钟，开启多线程调用这三个接口，用CountDownLatch控制同时返回数据，优化到了
 *                      1s左右
 *                  2.判断重复预约的代码直接打在数据库上，数据库撑不住呀，查询超时，还好没挂掉，就引入了redis做判重，将人的
 *                      身份证号码作为key，重复预约的先打回去
 *                  3.但是并发量一高，数据库还是撑不住，而且这样还是没解决快速返回预约状态的目标。就引入了mq，用的kafka，当时
 *                      是对比了四个常用的mq中间件，单论吞吐量的话，还是kafka和rocketmq比较好点，rabbitmq的延迟较低，但是
 *                      是用erlang写的，怕不便于维护，然后公司中大部分用的都是kafka，就选了kafka了
 *                  4.业务代码的设计思路大概是这样：
 *                      1.先进行库存预热，将预约的数量存进redis，
 *                      2.redis中存了身份证号码为key，还有值有 0 1 2 ， 0 代码预约失败（有过期时间）， 1 代表预约中 ， 2 代表预约成功
 *                      3.当一个请求进来的时候，判断redis是否有这个人的key，有的话证明预约过了，打回
 *                      4.没有预约过，redis直接扣除一个，然后将预约的消息发送给mq，去处理
 *                      5.redis将key设置为1，代表预约中，返回给前端预约中的状态
 *                      6.然后mq处理消息，预约成功则将key，变为2，失败就变为0，并且存入数据库失败原因
 *                      7.前端发起ajax短沦陷，每隔1s查询一下redis的那个key，为2就返回预约成功，为0就返回失败，并且查询原因返回
 *          4.然后服务器上又加了两台，搞了负载均衡，布了三个服务，压测的时候，发现等待的时间还是长，发现并发一大瓶颈还是在数据库上，
 *              因为业务原因，查询的数据有点多，让运维搞了个数据库集群，主从，分散一下读的压力。
 *          5.正式上线，系统还是扛得住一些，但是出现了超约的情况。原定500个，约了510个，后来研究发现是服务布了三台，结果没有加分布式
 *              锁，就加了lock，还好这个超约的也不多，技术上是引入了redission，在redis扣减的业务上加上了分布式锁
 *          6.还发现有一些类似黄牛的人，在预约时间前就开始疯狂发送请求，在日志一下子就出现一排相同的ip在预约，架构师说nginx可以开启
 *              一个配置，过滤请求频率很高的ip，然后我们又把存储日志的功能也单独分离了出去，日志也直接用mq去发送
 *     2.新版
 *          1.疫情期间，口罩急缺，政府免费发放，以预约的形式，一个旧的预约服务，qps只有四五百左右，要优化到6000左右，任务分配给了我们小组，做了几个通宵
 *          2.业务流程：发起预约，判断登录信息(拦截器判断)，校验数据合法性，判断是否重复预约，调用三个接口（每个接口平均1s）,通过接口数据身份认证与预约资格确认，
 *              查询预约库存，存入预约数据，返回预约结果
 *          3.难点1：
 *              1。三个接口的调用，每个接口要掉1s这样：通过设置全局线程池，io密集型的，核心数设置为cpu核心的两倍，或者根据阻塞系数，多线程同时处理三个接口，时间缩短为1s
 *          4.难点2：
 *              1.压测的时候，数据库撑不住并发，会出现连接超时，请求超时的情况，去数据库中查看cpu占用率很高，响应很慢，试着加大服务的连接池数量和mysql的最大连接数量，
 *                  可以抗住一时的压力，但是达到1000以上的时候，还是会出现问题。然后让运维去做了数据库的主从和独写分离，才正常
 *          5.难点3：
 *              1.采用什么样的预约方式比较好
 *                  1.同步预约：传统得预约方式，点击预约之后开始等待预约成功得消息，系统就一步步执行，占用socket连接，用户等待得时间也长，因为目前最大只能扩容出三台
 *                    服务器，这种方式如果用Nginx负载均衡一下，每台服务器要承受接近2000得qps，显然是不太行得。
 *                  2.异步预约：原先redis单纯用来判断重复预约，现在我们将预约时段和预约数量存入redis，做库存预热。然后请求进来后用Lua脚本将判断预约数量和扣减预约数量得
 *                    操作合并在一起，防止超约得情况，然后再引入消息队列，发送一条消息异步处理，然后直接返回正在预约中，请稍等。前台开启ajax短轮询，每隔2s查询一次redis
 *                    得预约是否成功。消息队列处理成功就将预约成功得Key存入reids，redis得qps扛得住。这个方案是会牺牲一些用户体验得，但是目前得系统资源下，做的来，不然
 *                    一下子得大并发容易崩溃
 *          6.难点4：
 *              1.限流怎么做
 *                  1.接口限流：然后因为当时那个预约服务得框架不支持引入hystrix，我们就用了gruva得RateLimiter得一个组件进行限流，服务限流到1000
 *                  2.nginx限流：因为后面发现，会有人写脚本进行不断请求预约，用Nginx得限制请求频率的模块限流
 *          7.难点5：
 *              1.前端：
 *                  1.预约的页面加载卡顿，url访问非常慢，然后发现，前端页面加上图片等资源，总共有接近2M，开启了Nginx的一个叫gzip压缩技术，还有开启了niginx缓存
 *          8.难点6：
 *              1.超约情况的出现，是用lua做的，原先是考虑用分布式锁，有两种方案，第一种是用set的一个指令，然后加锁加过期时间。第二种是用redisson的分布式锁，用
 *               trylock，如果尝试获取锁失败，就返回系统繁忙的提示。然后第一种因为有锁的开销，并发量不太行，第二种方式，一瞬间的流量进来，压测出现很多系统繁忙的情况
 *               也不适合。然后采用了lua脚本，将获取库存数量和减库存的操作用lua脚本执行，保证原子性，性能会好点
 *              2.两种方案都可以解决超约的情况：
 *                  1.使用lua脚本，将扣减库存的操作用lua脚本写，保证原子性。有个问题是redis-cluster集群模式下，无法使用lua
 *                  2.使用redission分布式锁，锁住扣减库存和判断库存的代码。问题是增加了锁的开销，而且会出现加锁的各种问题，使用分布式锁的吞吐量比使用lua小了一倍
 *          9.难点7：
 *              1.保证mq消息能到达
 * 4.你来XX这一年做了什么
 *      1.开始三个月主要跟着做XZ的一些业务，什么个人研判，稳定指数之类的，然后出差了两个月，部署新疆系统的服务啥的，对接警银数据
 *      2.后面跟翔哥一起搞数据治理的平台，就是那套基于Kettle，flink，doris，datax的数据仓库，还有一些标准化数据治理的事
 *      3.再后来搞龙岩的稳定指数系统，用一个低代码平台开发，国产化，主要做架构升级
 *      4.平时会有针对性地讨论一些业务的优化，比如个人研判缓存优化，资金分析研判优化之类的，mysql语句优化，数据存储技术选型啥的
 *      5.还有一个技术分享，讲的是用户画像系统架构解决方案，有研究了一阵子机器学习算法
 * 5.最近有在学习吗？学习啥？有看书吗？
 *      1.最近在看阿里巴巴大数据之路那本书，还没看完，对大数据还是有点兴趣的，而且这一片属于盲区，目前还在看数据技术选型架构方面的
 *          日志采集，离线开发平台，实例计算平台等。数据模型搭建还没去深入了解
 *      2.上回看的是用户画像工程化解决方案，因为当时提出说要建立主题库，和标签库，然后没人做过，标签模型如何提取，标签数据如何存储，
 *          如何使用等等，然后我就顺带去了解了一下，也做一个技术分享吧，就买了这书看
 * 6.你有什么优点？
 *      1.我比较喜欢去研究一些新的技术吧，并且喜欢将这些技术做分享啥的。
 *      2.在全院里面做了一次大型的技术分享，还有部门里面做了三次的分享
 *          1.大数据用户画像工程化解决方案
 *          2.一个Kafak的分布式监测框架
 *          3.基于clickhouse的数据分析模型
 *          4.引入datax数据同步框架，并且手写数仓与mysql之间的数据同步插件
 *          5.一个基于springcloudAalibaba的开源的低代码平台的引入，包括分布式锁，mq，sentinal，gateway,nacos之类的组件的适配
 * 7.项目中用到什么设计模式
 *      1.单例模式：创建全局线程池对象,es连接对象等等
 *      2.模板方法模式：
 *          1.在调用第三方的接口的时候，会用到模板方法模式，将数据的公用解析方法，参数的公用转换方法，放到公共抽象类中，子类可以重写这些方法，
 *          也可以直接调用父类的。另外子类还会实现一个统一的接口，重写其中调用借口定义的方法
 *      3.建造者模式，构建一个复杂的分析对象的时候会用到，比如以人为纬度，通过调用各种接口和数据库填充人物的属性，将这些业务算法的细
 *        节隐藏在不同的建造者中，有的时候只需要人的一两项属性
 *      4.策略模式：
 *          1.系统中excel批量数据解析系统，整体是用策略模式做的，比如就是定义一个excel处理数据的接口，然后实现类是各种不同的数据处理方式，
 *          比如账单的处理，人员的处理等等，分别有个编码一一对应，然后将编码和实现类put进一个map，或者是用注解注解实现类，
 *          在springboot加载的时候自动解析并装配这些实现类的bean到map中，kafka接收消息的时候，获取编码，得到实现类，执行对应的数据解析方法
 * 8.项目中怎么做的限流
 *      1.分布式限流
 *          1.nginx
 *              1.连接数限流模块
 *                  1.服务器流量异常，负载过大，大流量的恶意攻击和访问，会带来带宽压力，需要对同一个Ip的连接数，并发数进行限制
 *                  2.该模块只能对正在被处理的请求进行计数，可以设置返回状态码，和日志级别
 *              2.漏桶算法实现的请求限流模块
 *                  1.可以限制请求处理的频率，限制方法使用漏斗算法，每秒固定处理请求数，请求超过一定程度则直接抛弃
 *          2.redis限流
 *              1.redission分布式限流采用令牌桶思想和固定时间窗口，trySetRate方法设置桶的大小，利用redis key过期机制达到时间窗口目的，
 *                控制固定时间窗口内允许通过的请求量
 *      2.API限流
 *          1.应用开源工具包guava的限流工具类RateLimiter，然后设计一个注解，搞个aop切面，对每个api进行限流
 *      3.开源组件限流
 *          1.spring cloud alibaba sentinel 带监控平台，可配置，自由度高
 *          2.spring cloud hystrics 接口层限流，支持线程池和信号量两种方式
 *      4.限流算法
 * 9.分布式环境下如何保证线程安全，分布式的并发问题
 *      1.避免并发：分布式环境，出现并发问题，很难解决而且代价很大，首要想的是能不能从策略或者业务的手段上避免并发，比如合理的时间调度，避免共享资源冲突
 *      2.分布式锁：redis或者zookeeper等中间件都自带有分布式锁，当处理同一件事的时候，可以加索保证一致
 *      3.数据库：乐观锁CAS或者版本号
 * 10.设计模式大类以及熟悉哪些
 *      1.创建型：单例，工厂方法，抽象工厂，原型，建造者
 *      2.结构型：适配器，代理模式，装饰器模式，外观模式，桥接模式，组合模式，享元模式等
 *      3.行为型：策略模式，责任链模式，观察者模式，命令模式，备忘录模式，解释器模式
 *
 *
 * @author
 * @created 2022/1/23 14:23
 */
public class Project {
    public static void main(String[] args) throws InterruptedException {
        ArrayList<int[]> objects = new ArrayList<>();
        for (; ; ) {
            int[] ints = new int[1024 * 10 * 10];
            objects.add(ints);
            TimeUnit.MILLISECONDS.sleep(50);
        }
    }
}
